In the development of application program interface programs (APIs) supporting asynchronous transfer mode (ATM) connection management, existing network API models, such as UNIX sockets APIs and System V Release 4 ("SVR4") transport layer interface (TLI) APIs may be used to develop a wide variety of client/server applications. Implementations of the sockets API libraries exist for the popular operating systems including BSD UNIX.RTM. (BSD) and SVR4 UNIX.RTM., DOS/Windows.RTM., Windows NT.RTM. and Systems 7.RTM.. The SVR4 TLI API may also provide a signal interface for ATM applications.
Providing a socket simulation API function library for ATM would assist the migration of existing network applications to a non-Internet Protocol (IP) ATM environment. However, without definition of an underlying entity or API layer to manage ATM Switch Virtual Circuits(SVCs), modifications to the sockets API would be extensive and require application writers to learn and work with ATM concepts foreign to the existing IP environment.
Another existing limitation with known interfaces is that, for non-native ATM systems, such as LAN Emulation, RFC-1483 and RFC-1577 systems, there is no quality of service (QOS) capability in virtual channels. This limitation relates to the competition for a virtual channel (VC) when two nodes attempt to communicate with each other, while at the same time they compete for network resources such as VC bandwidth and services. Without a level of QOS there is no way to determine which node should preferentially receive the VC resources while one application may be more important to the operation of a system or user than a second application. With current ATM interface technology there is no way to preferentially allocate resources on a VC. Without the ability to limit, control, and give priority to various applications, effective VC management is not possible.
Another limitation associated with current VC assignment technology for a network environment is that many APIs only address IP applications. Local area network (LAN) emulation (LANE), on the other hand, uses many different types of protocol. Because of this limitation, currently there is no way to provide a degree of QOS on a per application basis.